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(54) Computer systoms 

(57) A physical computer system of a first type performs an emulation session In which it emulates a 
computer system of a second different type and in which an operating system is operating on the emulated 
computer system. Booting the emulation software and the operating system can take a long time. To reduce 
this problem, when the emulation session Is shut-down, the values of those variables necessary to define the 
state of the emulated computer system at the start of the shutting-down step are stored. Then, when 
subsequently starting a emulation session, the values of the variables are restored from the stored values so 
as the restore the emulated computer system to Its state at the start of the preceding shutting-down step. 
Typically, the storing of the variables during the shutting-down step and the restoring of the variables in the 
subsequent starting step can be arranged to take far less time than the time to boot-up the operating system 
from scratch. 
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Cbmputer Systems 
DESCRIPTION 

This invention relates to computer systems and methods of operating them. 

A number of different computer systems have gained great popularity over the years, 
examples being IBM and IBM-compatible "PCs'* running the IBM-DOS or Microsoft-DOS 
(MS-DOS) operating system, younger generation PCs running various versions of the 
Microsoft Windows operating system, Apple Macintosh machines running Apple's System 
operating system, and various Unix machines designed primarily or exclusively to run 
various versions of the Unix operating system. A vast number of applications programs have 
been written for Windows, many of ihem being particularly aimed for personal use, such 
a personal financial programs, games, personal organisers. Also, for more general puipose 
programs, such as word processors, spreadsheets and the like, a greater variety of programs 
are commonly available for Windows than for other operating systems. This has therefore 
led to the problem that somebody who likes to use a particular DOS or Windows application 
on their home computer or notebook computer may not be able to use their homework data 
with the same application on their office computer unless their office computer uses the 
DOS or Windows operating system. Also, an application which is particularly suited to a 
particular job may be available to lun only on the DOS or Windows operating system. If 
some other operating system is all that is available, it may be necessary to choose a less 
suitable application which can run on that operating system. 

In order to deal with the problems mentioned above, emulation software has been developed, 
and a notable product is SoftWindows produced by Insignia Solutions of High Wycombe, 
GB, and Santa Qara, California, USA. One example called "SoftWindows 2.0 for 
Powermac" can run on an Apple Power Macintosh machine ninning the Apple System 7.1 
operating system. This emulation software causes the physical Macintosh computer to 
emulate a PC having an Intel 80486DX processor and 80487 maths co-processor. 1MB of 
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Intcl-likc conventional memory and up to 2GB of Intel-like extended memory and 32MB 
of Intel-like expanded memory (depending upon the amount of physical Macintosh 
memoiy), two PC-like hard disks (C: and D:), a 256 colour SVGA display, an enhanced 
IBM-style 101 -key keyboard, and a number of other features commonly provided by 
5 younger generation PCs. The emulation software package also includes MS-DOS version 
6.22 and Microsoft Windows version 3.11. Accordingly, when SoftWindows is loaded on 
the physical Macintosh computer for a SoftWindows session, Windows applications can be 
run on the computer, and the computer appears to the application and to the user as if it 
were '486 PC. 

10 

In 1995, Microsoft launched a new version of Windows called "Windows 95." This 
operating system is said to provide a number of attractive features such as an improved user 
interface, easier customisation, easier networking, faster performance, and improved file 
handling and memory management. However, Windows 95 does suffer from disadvantages 

15 compared with Windows 3.11: the required and preferred memory capacities arc higher; the 
required hard-disk space is larger; and it takes a significantly longer time to load and start 
up. When Windows 95 is used with emulation software, this last disadvantage is even more 
pronounced. In one test carried out using a 99MHz HPPA Unix platform and software 
emulating an Intel 40486 processor, the time taken to load the emulation software and 

20 Windows 95 was 1 3/4 minutes. When Microsoft Word from Miaosoft Office 95 was then 
immediately started up, the total time between initiatuig the emulation session and being 
able to open a document in the word processor application was 2Vi minutes. 

The problem with which the present invention is concerned is to speed up the time taken 
25 between initiating an emulation session and being able to start using an application. 

In accordance with one aspect of the present invention, there is provided a method of 
operating a physical computer system (such as, but not exclusively, an Apple Macintosh or 
a Unix machine) of a first type, the method comprising the steps of: performing an 
30 emulation session on the physical computer system in which the physical computer system 
emulates an emulated computer system (such as, but not exclusively, a PC) of a second 
different type and in which an operating system (such as, but not exclusively, Windows 95) 
is operating on the emulated computer system; shutting-down the emulation session, the 
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shulting down step including the step of storing the values of those variables necessary to 
define the state of the emulated computer system at the start of the shutting-down step; and 
subsequently starting a emulation session in which the values of the variables are restored 
from the stored values so as to restore the emulated computer system to its state at the start 
5 of the preceding shutting-down step. Typically, the storing of the variables during the 
shutting-down step and the restoring of the variables in the subsequent starting step takes 
far less time than the time to boot-up the operating system from scratch. 

Preferably, the session starting step includes the steps of: determining whether or not values 
10 have been stored defining the state of the emulated computer system at the start of a 
preceding shutting-down step; and if not booting the operating system to an initial state. 
Also, the session starting step preferably includes the steps of: determining whether or not 
values which have been stored defining the state of the emulated computer system at the 
start of a preceding shutting-down step arc valid; and if not: deleting those stored values; 
15 and inhibiting the starting of an emulation session using those values. One way of emulating 
the files (typically numbering hundreds or thousands) stored on emulated C: and D: hard 
disk drives of an emulated PC is to store the data in two physical "container** files on the 
physical computer system. If these container files are changed between shutting down an 
emulation session and starting a subsequent emulation session, then the variables stored 
iO during the shutting down step will not be valid for the changed container files, and problems 
will arise. Therefore, one example of the validity determining step is to check whether any 
changes have been made to the container files. 



In the case where the operating system of the emulated computer system provides a 
graphical user interface, the shutting-down step preferably includes the step, prior to the 
step of storing the values of the volatile variables, of placing the emulated system in a state 
in which the graphical user interface is not displayed. For example, in the case of Windows 
95, opening a full screen DOS box rumiing in the foreground has the effect of forcing 
Windows 95 to save the state of its desktop into the emulated Intel memory, from which the 
values of the desktop variables can be easily stored during the shutting down step, as 
compared with saving the state of the display device. 



case where the emulated computer system employs a power management system. 
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prefexably in the shutting down step, at least one shutting-down request is made to the 
power management system, which in turn makes at least one shutting-down request to the 
operating system of the emulated computer system. Again, in the case of Windows 95 for 
example, performing a partial shutdown in collaboration with an advanced power 
5 management system causes Windows 95 to perform any aaions it feels necessary before 
a long period of dormancy. 

In the case where the emulated computer system employs a plurality of function pointers, 
preferably: a database is maintained of every function to which the function pointers can 

10 point; during the shutting down step, the values of the function pointers are encoded 
according to the positions of the respective functions in the database; and during the session 
starting step, the encoded values of the function pointers are decoded according to the 
functions at the respective positions in the database. This therefore deals with possible 
problems arising from functions being loaded at different addresses in different emulation 

15 sessions. 

In accordance with another aspect of the present invention, there is provided a physical 
computer system of a first type, comprising: a volatile memory for storing values of 
variables; permanent storage means for storing values of variables; an operating system for 

20 operating on a computer system of a second different type; means for performing an 
emulation session on the physical computer system in which the physical computer system 
emulates the computer system of the second type and in which the operating system can 
operate on the emulated computer system; means operable to shut-down such an emulation 
session including storing in the permanent storage means the values of those variables in the 

25 volatile memory necessary to define the stale of the emulated computer system at the start 
of operation of the shutting-down means; and means operable to start a subsequent 
emulation session including restoring from the stored values in the permanent storage means 
the values of the variables in the volatile memory so as to restore the emulated computer 
system to its state at the start of the preceding operation of the shutting-down means. 

30 

A specific embodiment of the present invention will now be described by way of example 
with reference to the accompanying drawings, in which: 



Figure 1 is a flow diagram showing how a known SoftWindows shutdown module is 
modified in one embodiment of the invention; 



Figuie 2 is a flow diagram showing how a known SoftWindows startup module is 
modified in one embodiment of the invention; 

Figure 3 which is made up of Figures 3A, 3B and 3C, is a more detailed flow diagram 
of time capsule creation and preliminary steps thereto. 

In this specific description, the novel features will hereinafter be referred to by the name 
"time capsule." Also, in this description "base" refers to source modules which apply to all 
physical platfonns on which the system may be run, and "host" refers to a particular 
physical platform and to source modules which are specific to that particular platform. 
"HFX" refers to Host Filesystem extension, which is a known feature of SoftWindows 
which allows directories in the host file system to appear as network drives in the emulated 
PC environment. "Smartcopy" refers to a known clipboard feature of SoftWindows which 
allows data and commands to be transferred between the host environment and the emulated 
environment. "APM" refers to Advanced Power Management and in particular to the 
features set out in the document "BIOS Interface SpecificaHon", Revision 1.1, September 
1993, available from Intel Corporation, Literature Distribution Center, P.O. Box 7461, Mt. 
Prospect, IL 60056-7641, USA (order no. 241704-001) and from Microsoft Corporation. 
Hardware Vendor Relations Group, 1 Microsoft Way, Redmond. WA 98052, USA (part no. 
781-1 10-XOl). 

The objective of the time capsule features in the embodiment of the invention is to side-step 
the problem of slow Windows 95 start-up time in SoftWindows. As mentioned above, on 
an otherwise unloaded 99MHz HPPA host platform, using state of the art 80486 CPU 
emulation technology (as of 11 December 1995). it takes one and three quarter minutes to 
get to the stage where it is possible to start up Windows 95 applications. Adding the time 
required to start up an application (e.g. a ftirther forty seconds to start up MS Word from 
Office 95) yields an overall wait of two and a half minutes before the user can even 
consider opening the document they arc planning to work on. Even if emulation performance 
were to double, the user would still would have an enforced wait of one whole minute 
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watching SoftWindows emulate code which is totally spurious with respect to their business 
needs. 



Since there is no real hardware present in the PC being emulated by SoftWindows, all of 
5 the state of this PC is available as the content of the multitudinous variables inside the 
SoftWindows program itself - for example, the 16MBytes of memory in the emulated PC 
is, in effect, a byte array with 16,777,216 elements. Accordingly, it is, in principle, possible 
to allow Windows 95 to complete bootstrapping and then record the values of all of the 
variables necessary to remember the complete state of the emulated PC and terminate 
10 SoftWindows. At a later lime, a new SoftWindows session can be started which, rather than 
emulating the many millions of instructions to return to the previously saved state, restores 
the recorded state back into the relevant SoftWindows variables and then continues the 
emulation process. Hierefore, the Windows 95 session continues from the point it had 
previously reached in a fraction of the time it would take to get there from first principles. 

15 

One might imagine that this saved state could be used over and over again to get back 
repeatedly to the same point in the Windows 95 session. This is, in fact, only safe if other 
elements of the Windows 95 session's state are constant - in particular, the state of the two 
"container files." The container files arc physical files in the physical computer system 

20 which contain the data which is used to emulate the C: and D: hard disk drives in the 
emulated PC computer system. It is important to realise that the saved state of the emulated 
PC (including Intel memory image) contains important "reflections" of the state of the C: 
and D: drives. There may be files open, directories cached, desktop patterns and/or software 
drivers loaded, and so on. The C: and D: drives are not "removable" media, so Windows 

25 95 is not prepared for the contents to change suddenly without its knowledge. This is 
effectively what would be happening if an attempt were made to restore a recorded state 
without restoring the contamer files as well. In the current context, this therefore limits the 
usefulness of the time capsule technique to situations where the recorded state is known to 
be relevant to the state of the container files. In practice this means that the technique is 

30 most useful for storing a running Windows 95 session strictly from the end of one 
SoftWindows session to the start of the subsequent SoftWindows session. 

Figures 1 and 2 illustrate an overview of how the time capsule feature is hooked into the 
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SoftWindows shutdown process (Figure 1) and start-up process (Figure 2). 



ITie shutdown process is preferably invoked by the nonnal user interface quit mechanism 
rather than a separate new user interface mechanism. In the shutdown process of Figure 1, 
5 the time capsule code determines in step 10 whether a time capsule shutdown is possible 
or not. Time capsule shutdown is prohibited if, for example, Windows 95 not running, or 
if the Windows 95 session has any HFX files open for writing. If time capsule shutdown 
is not possible, the user will be presented with the normal SoftWindows shutdown dialogue 
in step 12. However, if time capsule shutdown is possible, a new dialogue is presented in 
10 step 14 which offers the user three choices: Quit with the creation of a time capsule; Quit 
without the creation of a time capsule; and Cancel. The two quit options display a warning 
message to the user. The latter one (without time capsule creation) shows the same warning 
as a conventional SoftWindows shutdown. i.e. that the user will lose unsaved work. The 
former, default quit option, displays a warning message that stresses the following points: 
15 the running Windows 95 session will be saved to disk for automatic re-start next time 
SoftWindows is run; the user really should save any unsaved work before proceeding (if the 
user decides that they want to quit Windows applications after reading the warning, they 
should select the Cancel option); and the icstartability of the Windows 95 session at the start 
of the next SoftWindows session is dependent on the user not using the container files in 
20 any other way in the mean time, not altering any files that were open for reading over HFX 
in the meantime, and not altering their configuration in any way. If the user chooses to 
continue with time capsule shutdown, the time capsule creation process commences in 
partnership with Windows 95. This means that the SoftWindows session appears to carry 
on for a short while, and the user interface may be provided some visual feedback during 
25 this time. The time capsule creation system can call the user interface back once a second 
to drive this, for example in direct response to calls that Windows 95 makes back on 
SoftWindows. 



30 



In preparation for the creation of the time capsule, in step 16 SoftWindows causes a DOS 
program to run in the Windows 95 session; this program is set-up to run in a full-screen 
DOS box. This causes Windows 95 to save its desktop into the emulated Intel memory 
which means that SoftWindows need take no further action to save the Windows desktop, 
other than to save the state of the emulated Intel memory. The final call back to 



SoftWindows from Windows 95 is an APM "System Suspend" call in step 20. Windows 95 
makes this in response to an earlier "Request System Suspend" message being passed to it» 
in step 18, when it poUs for any power management event. Tliis is the ideal time for 
SoftWindows to aeate the time capsule, since Windows 95 will have performed any actions 
it feels is necessary before a long period of dormancy. The time capsule is then created and 
SoftWindows exits. 

It should be noted that the APM dialogue is not allowed by Windows 95 if it detects that 
real mode network drivers are installed (such as used by the current version of Softnode 
available from Insignia Solutions). This does not prevent the time capsule shutdown from 
proceeding. It does proceed^ but with a warning message that there is a risk of more data 
being lost if the time capsule becomes unusable (for example due to hard disk changes). The 
user then has the choice of continuing or aborting the time-capsule production, and if they 
abort, SoftWindows continues running Windows 95 as before. 

In step 22, the time capsule is created by saving the current values of all of the volatile 
variables defining the state of the emulated computer system. The precise form which the 
time capsule takes may be dependent on the platform being used. The time capsule takes 
up space on the disk of the physical computer system when SoftWindows is not running. 
It contains the content of the whole of emulated Intel memory and other states. The Intel 
memory is the major part of the saved state, so the space required on disk is fairly directly 
controlled by the size of this. The additional states will probably never exceed 1Mbyte. 
Accordingly, if the size of the emulated Intel memory is 16MB, the size of the time capsule 
is likely to be less than 17MB. Investigations into compressing the stored version of Intel 
memory in the time capsule have been made, but indications are that this will significantly 
increase the time taken to read and write the time capsule. 

Finally, in step 24, the shutdown process terminates the current SoftWindows session. 

Referring to Figure 2, when SoftWindows is started up, it checks in step 30 to sec whether 
a time capsule from a previous session is present. If not, then SoftWindows and Windows 
95 are loaded from scratch in step 31 in the conventional way. However, if a time capsule 
is present, the startup process then checks in step 32 whether the time capsule is valid. If 



so, the recorded emulated PC state from that time capsule is loaded in step 34 and the 
Windows 95 session resumed. In step 36, an APM "Update Time Notification" is sent to 
Windows 95 the next time it polls the SoftWindows APM BIOS for any power management 
events. Hiis ensures that the Windows 95 time is updated from the host platform's real time 
clock. In step 38, the time capsule is deleted when it has been successfully loaded. It cannot 
have any further relevance since the user is running Windows 95 and may well be changing 
the contents of the C and D: container files. 

The time capsule subsystem preferably has the facility to allow the user interfrice code for 
any particular platform to determine the number of times the ninning Windows 95 session 
has been restarted from a time capsule. A value of zero means that this is a normal, first 
session. 

If, in step 32, it is determined that the time capsule is not valid, for example because the 
container files for the C: and D: drives have changed, a panel explaining the problem is 
displayed. When the user continues from this point, the time capsule is deleted in step 40, 
and SoftWindows terminates immediately in step 42. If the user restarts SoftWmdows again 
at this point, no time capsule will be found in the subsequent step 30, and Windows 95 will 
boot up from scratch in step 31. 

There now follows a more detailed description of steps 10, 14, 16, 18, 20 and 22 of the 
shutdown process described above with reference to Figure 1. Hie time capsule shutdown 
is invoked by the host user interface's normal "Exit SoftWmdows" mechanism. In step 10, 
the host user interface code uses the API with the new time capsule subsystem to determine 
whether it is even possible to create a time capsule at the current time, using a routine called 
"get_time_capsule_save_state".This routine returns two values of types "icstat^status^value" 
and "tcerr^status.value" to the caller indicating the feasibility of creating a time capsule at 
this time. The first value, of type "tcstat_status_value", can take one of the values given in 
Table 1. 



TABLE 1 



TCSTAT.SAVE_IMPOSSIBLE 


It is not possible to create a time capsule at this 
time, the second value gives more detail. 


TCSTAT_SAVE_POSSIBLE 


It is possible to create a time capsule at this time, 
although conditions arc not ideal, the second value 
gives more detail. 


TCSTAT_SAVE_RECOMMENDED 


As far as the time capsule subsystem can (ell, 
conditions are ideal for the creation of a time 
capsule. 



The user interface then proceeds to call either the original SoftWindows "terminateQ" 
function or a new *'time_capsuleJerminateO" function according to the values letumed 
(possibly in conjunction with the results of further interaction with the user). The second 
value returned by this function, of type "tccrr_status_valuc", communicates details of any 
problem. Details of error conditions that make it impossible to create or restore a time 



capsule are given in Table 2. 
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Symbolic Error Name 


Description 


TCERR. 

APM^REQUEST.REJECTED 


Windows 95 has rejeaed the APM request to suspend 
- this can happen if old-fashioned real-mode drivers 
are present (see note 3). 


TCERR. 

CMOS.CHANGEO 


The content of emulated CMOS RAM has been altered 
since the time capsule was created (see note S). 


TCERR_ 

CX)NFIG,CHANGED 


The configuration of SoftWindows has been altered 
since the timecapsule was created (see note 5). 


TCERR 

a)UU>NT_CLOSE 


Internal Error (see note 6). 


TCERR_ 

COULDNT„OPEN_FOR_READ 


Internal Error (see note 6). 


TCERR_ 

CX)UU)kr.OPEN.FOR_WRrrE 


Internal Error (see note 6). 


TCERR. 

COULDlvrr_READ 


Internal Error (see note 6). 


TCERR. 

COULDNT.WRITE 


Internal Error (see note 6). 


TCERR 

C.DRH^.CHANGED 


The container file representing the emulated C: drive 
has been altered since the time capsule was created (see 
note 5). 



Symbolic Error Name 


Description 


TCERR 

DIFFERENT_HOST_MACHINE 


Networking was active when the time capsule was 
created and it is being attempted to re-use the time 
capsule on a different machine - this is not supported 
because Windows 95 doesn't expect the network 
address to change once it's started up (see note 4). 


TCERR_ 

DIFFERENT.SoflWindows 


fsee note ^ 


TCERR 

D.DRT^.CHANCED 


The container file representing the emulated D: drive 
has been altered since the time capsule was created (see 
note 5). 


TCERR_ 

ENUMERATION^FAILURE 


Internal Error (sec note 6). 


TCERR^ 
HFX.CHANGED 


An HFX file that was being read when the time capsule 
was created has been changed in the interim (see note 
5). 


TCERR 

HFX_FILE_IN_USE 


Internal Enor (see note 6). 


TCERR 

HFX_SEEK_ERR 


Internal Enor (see note 6). 


TCERR 

HFX_SYSTEM_ERR 


Internal Error (see note 6). 


TCERR_ 

mCmKJIS. J _rJ\\JOlJlm 


Insufficient memory (see note 4). 


TCERR_ 


It is not possible to create a time capsule at this time 
because the Windows driver has somehow reactivated - 
this is normally because the user has tried to shut down 
SoftWindows when things were going on within the 
Windows 95 session - the solution is to try again when 
things have quietened down (see note 1). 


TCERR 

NETWdRK_REINIT_FAILED 


Internal Error (see note 6). 


TCERR_ 
NO,APM 


The Windows 95 Session has not established an 
Advanced Power Management dialogue with 
SoftWindows' APM BIOS (see note 2). 


TCERR 

NO.SMARTOOPY 


The SmartCopy Windows 95 application is not running 
(see note 1). 


TCERR 
OK 


No Error 


TCERR. 

SCSLCONFIG.CHANGED 


(see note 4). 
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Symbolic Error Name 


Description 


TCERR. 

SnUNG.PROBLEM 


Internal Error (see note 6). 


TEMPORARY_CPU_PROBLEM 


It is not possible to create a time capsule at this time 
because of internal conditions within the Intel CPU 
emulation subsystem — this is normallv hefrfmc^ thm 
user has tried to shut down SoftWindows when things 
were going on within the Windows95 session - the 
solution is to try again when things have quietened 
down (see note 1). 


rasRR 

WRITABLE_HFX 


An application is currently in the process of writing to 
an HFX drive (see note 1). 


TCERR. 

WRONG^SMARTCOPY 


An earlier version of SmaitCopy is running than one 
that will property support time capsule shutdown (see 
note 1). 



10 The significance of the notes in Table 2 is given in Table 3. 



TABLE 3 



1 


This error can cause get_time_capsulc save state to return TCSTAT SAVE 
IMPOSSIBLE. 


2 


Tliis error can cause gctjimc_capsule_save state to return TCSTAT SAVE 
POSSIBLE (as opposed to the preferred TCSTAT_SAVE_RECOM\ffiNDED). 


3 


Although this error doesn't affca the result of gel time capsule save stateQ, it 
can occur later in a time capsule shut-down; this error doesn't prevent the time 
capsule from being created, but it will be a more risky time capsule given, that 
APM could not be used. 


4 


This error can occur when loading a time capsule and prevents successful loadine 
of the time capsule. 


5 


This error can occur when loading a time capsule and prevents successful loading 
of the time capsule (i.e. as above) - but in-house within Insignia Solutions Pic. 
this error can be configured to be ignored for testing purposes. 


6 


Unexpected error. 



Steps 16, 18, 20 and 22 shown in Figure 1 are initiated by a routine called 
"time_capsulc_terminate." This routine is the one that the host user interface code calls to 
actually initiate the shutting-down of SoftWindows with the creation of a time capsule. TTie 
single input parameter is a pointer to a routine the host user interface code wishes to have 
called once a second to provide visible feedback to the user that shutdown is proceeding. 
The process of shutting down SoftWindows and creating a time capsule is relatively 
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complex (in comparison with a traditional shutdown) and involves interaction with Windows 
95 and some Windows 95 applications. It is should be noted that this call just kicks off the 
whole process - it does return (and relatively quickly, at that). TTie time capsule shutdown 
process depends on the user interface code returning to the CPU emulation after having 
5 called "time_capsulcjcnninate." Other routines called "time_capsulc_apm_susp^ 
•'time_capsuleJenn_bop" and "time_capsuie_apmjenn'*, all co-operate in the process of 
getting the Windows 95 session into an appropriate state for saving into the tunc capsule 
as shown in Figure 3, which is hereby incorporated into the description. One significant 
requirement of the state Windows 95 should be in (in order to Caciiitate the saving into a 
10 time capsule) is that the Windows desktop be completely obscured by a fiill-scrccn DOS 
box running in the foreground. This has the desirable effect of forcing Windows 95 itself 
to save the state of the Windows 95 desktop into Intel memory (which is trivial to save into 
the time capsule in comparison to the detailed saving of the display device's state). 

15 In an early prototype of the invention, the time taken to shutdown SoftWindows was 
sometimes excessive. The main culprit turning out to be SUSPEND.COM itself which was 
busy waiting in the fiiU-screen DOS box and not allowing Windows 95 to proceed. In order 
to alleviate this problem, SUSPEND.COM may be arranged to perform 
VM^RELEASE^TIMESLICE calls. In order to improve further the speed of operation and 
if no software is found which takes specific advantage of the User Shutdown APM dialogue, 
then all of the steps shown on the shaded background in Figure 3 may be omitted. 

The final routine shown in Figure 3. "time.capsulc.apmjerm", calls a routine called 
"save_SoftWindows.state" to save the state of SoftWindows. It uses the same host time 
capsule manipulation routines as used to open the time capsule (and as described below) for 
writing and then calls the save routines in each SoftWindows subsystem in turn. Each 
subsystem's save routine saves the necessary global state in order to be able to continue 
operating successfully at the start of the subsequent SoftWindows session with the software 
still running in the Windows 95 session. None of the state saved must rely on anything that 
cannot be guaranteed to be still valid at the start of the next session (e.g. the load address 
of the SoftWindows executable). Since function pointers are frequently used in various 
SoftWindows subsystems, the time capsule subsystem provides a mechanism to allow the 
conversion of such pointers into safe ordinal numbers and back again, as described below. 
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Hie save routines for the SoftWindows subsystems preferably do not damage the subsystems 
they are saving. It is quite possible, for example, that the creation of the time capsule might 
fail through insufficient disk space. In such a case, SoftWindows should preferably be able 
to continue running the user's Windows 95 session. If an error condition occurs at any stage 
during the creation of the time capsule, a time capsule routine called 
"flag^time_capsule_eiror" is called with the appropriate error code. This docs not actually 
divert the flow of control during time capsule creation. A check is made at the end of time 
capsule creation to see if any error was flagged. If so, the first such error is reported to the 
user via a call on a host routine called "hostjime_capsule_write_status" which informs the 
user of the problem. After the user acknowledges the existence of the problem, 
SoftWindows continues to execute as it did before the shutdown attempt was made. The user 
can then attempt to resolve the problem and try again or alternatively can quit Windows 95 
and shutdown without creating a time capsule. 

There now follows a more detailed description of the loading of a time capsule as shown 
at steps 30 to 34 in Figure 2. When a SoftWindows session starts up, much of the usual 
initialisation code is performed regardless of the existence of a saved session in a time 
capsule. To be precise, all code up to just before the end of the "resetQ" function that gets 
called by "Reset BOP" in the SoftWindows emulated ROM gets executed. At this point, the 
majority of emulated hardware components have been initialised and the video subsystem 
is in its standard mode 3 configuration (80x25 character cells), the same as was in force 
when the time capsule was created (because of the full-screen DOS box that was running 
in the foreground, also in mode 3). At this time, a time capsule subsystem routine called 
"time_capsule_initialiseO" is called from within "resetQ." If no time capsule is found, this 
routine returns without doing anything significant and SoftWindows starts up as normal. If 
a time capsule is found, then a routine called "load_SoftWindows_stateO" is called to load 
the saved SoftWindows state from the time capsule. 

The "load_SoftWindows_stateO" routine is local to the time capsule subsystem. It performs 
the converse operation to that of "save^SoftWindows^statcQ" described earlier, that is, it 
calls the time capsule load routines of each SoftWindows subsystem in turn, in the same 
order that the save routines were called during time capsule creation. Function pointers 
loaded from the time capsule need converting back into live function pointers, as described 



in further detail below. Some subsystems will need to allocate memory to accommodate the 
information that is coming out of the time capsule; the success of all such allocation 
requests is checked, and if any fail, the routine "flag.timc.capsule.cnorO". mentioned 
above, is called with the error code 'TCERR.MEMORY.PROBLEM" (see Table 2). 

Ihcrc now follows a description of routines provided by the time capsule subsystem for use 
in the savcyioad routines for individual SoftWindows subsystems, other than the routines for 
handling the conversion of function pointers to/from time capsule safe values, which are 
described later. The routine "flag_time,capsuIe_error" mentioned above flags that an error 
has occurred. It can be called during time capsule creation or time capsule loading, but the 
behaviour is different in the two environments. During reading, a call on this routine reports 
the error to the user via «hostjimc_capsule_read.status Q". The value for "must^quit" that 
gets passed to this routine is determined from a table in a header file "timccap.h" that 
indicates which error conditions are fatal during time capsule loading. During writing, the 
error value is noted if it is the first error to occur, and subsequent ones are ignored. The 
value noted can be interrogated by calling a routine "timecapsule^error^statusQ" Hie 
routine "timccapsule.ciror.status" returns any error status that has been flagged during time 
capsule creation. TTie routine "doing.time,capsuIe_shutdown" returns a boolean value 
indicating whether a time capsule shutdown is currently in progress. TTie routine 
"get_time_capsule_vintagc" returns a value that indicates the number of times that the 
current session has been restored from a time capsule. A value of zero indicates that no time 
capsule loads have been performed. It is useful that this information be available via the 
user interface somewhere to help technical support personnel determine whether problems 
encountered in the field can have any time capsule component eliminated from enquiries. 
(If it happens at vintage 0, it is almost certainly not a time capsule error.) 

niere now follows a description of the mechanism provided by the time capsule subsystem 
to facilitate the storing and reloading of function pointers to/fitim the time capsule. This 
functionality relies on a database of all functions that can ever be poimed to by variables 
lhat need to be saved/restored to/from the time capsule. The database is actually distributed 
amongst all relevant SoftWindows source files. The entry for any particular function is in 
a table in the same source module in order to avoid having to make functions global that 
were not before time capsule functionality was implemented. The format of the time capsule 



function database for an imaginary SoftWindows source module XXX is as follows, the 

name "fnar" denoting function array): 

#ifdcf TIME.CAPSULE 
^include "timecap.!!" 
/• 

* Export details of all functions in this module that can ever get pointed to 

* by variables that get put into the time capsule: 
V 

timecapFuncNode XXX £nar[] = 
{ 

tcapFuncNode (local_func_l), 

tcapFuncNodc (local_func_N), 
tcapFuncNodeTerminator 

}; 

#cndif /• TIME_CAPSULE V 
This table is hooked into the time capsule database by the inclusion of the appropriate 
declaration in the appropriate header file and the appropriate reference in the appropriate 
"fnarar** (Array of Function Anays) as follows: 

For a Base file: 

timecap.h and base_&iarar in SMASTER/base/support/timecap.c 
For a Host file: 

hostjcap.h and host_fnarar in the appropriate host directory. 
Having included all functions in the time capsule function database by including such tables 
in ail relevant SoftWindows modules, it is now possible to use two subroutines 
"tcap_cncode_fn_ptr" and "tcap_decode_fo_ptr" to convert function pointers to and from 
numbers which are safe to include in a time capsule. The routine "tcap_encodc_fn_ptr" is 
used to convert a function pointer in situ to a number that is safe to include in a time 
capsule. A function pointer is not safe, because when a time capsule is reloaded in a 
subsequent session, the function may be loaded at a different host address. The single 
parameter is the address of the function pointer variable to convert. This routine works 
simply by traversing the time capsule function database, counting as it goes and stopping 
when it finds the correct entry. The count value that is reached when the right entry is found 
is written over the function pointer whose address was supplied to "tcap_encode_fn_ptr". 
Note that a null pointer always returns a count of zero. Preferably, the values returned are 
all biased by a large 32-bit number to make then more easily recognisable in a time capsule 
for debugging purposes and to reduce the possibility of a small positive integer being 
confused for a converted function pointer in error situations. Note that if a subsystem 



converts one of its function pointer variables in situ for writing to a time capsule during a 
time capsule shutdown, it must immediately replace it by calling "tcap_decodc_fn_ptr". 
below, or by restoring a saved value if it prefers. This is in case the time capsule creation 
process fails and SoftWindows needs to continue running. It is a fatal error if the value in 
5 the function pointer variable is not found in the database. 

The routine "tcap_decode_fn_ptr" performs the converse operation to "tcap_cncode_fn_ptr", 
above. It traverses the time capsule function database in the same manner, again counting 
as it goes. When its count reaches the value that is in the function pointer variable whose 
10 address was passed, taking into account the bias that had been applied to it, the function 
pointer from the database entry reached is written to the function pointer variable whose 
address was passed. 

There now follows a description of the support each host must provide to allow the base 
15 time capsule features to work. The base only accesses the time capsule through these 
routines and makes no assumptions on the precise nature of the time capsule other than 
those stated here. 



Firstly, the routine called "host.open^writcjimc.capsule" requests that the host opens a 
20 new time capsule for writing, overwriting any existing time capsule and creating a new one 
if required. The time capsule is written sequentially, so that no random access is required. 

The routine "host.writc^string^tiine.capsule" writes the NULL terminated string supplied 
to the time capsule. 
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The routine "host_write_datajime_capsule" writes the requested number of bytes to the 
time capsule from the specified address. Note that if any error is reported via 
"fIag^time_capsulc_cirorO", by the base or the host, during the creation of a time capsule, 
the flow of control is not diverted; each subsystem is still called to dump its data to the time 
capsule. This means that the host write routines must be able to tolerate (i.e. ignore) calls 
made from the base even after a host error condition (such as disk full) has occurred. Any 
tidying up after the error condition may be left until the call on "host.closejime^capsuleQ" 
if desired. 



The routine "host_write_var_time_capsule'' does not need to be provided by the host, it is 
actually a macro In "timecap.h", but is included here for completeness. 

The routine "host_time_capsule_write__status" talks to the host user interface code to make 
an appropriate error message get displayed on the screen to explain to the user what went 
wrong with time capsule creation. 

The routine "host.open.ieadjime.capsule" attempts to open an existing time capsule for 
reading. A value of TRUE should be returned if the time capsule exists. Note that this is 
TRUE even if it is um^eadable in some way. If this is the case, the host should note that 
there is a problem by calling the base routine "flag^time_capsule_errorO" with the enor 
code "TCERR_COULDNT_OPEN_FOR_READ** (see Table 2) and return TRUE all the 
same. The routine should only return FALSE if there is no time capsule found and a normal 
SoftWindows boot is required. 

The routine "host_chcck_string^time_capsule_err" checks the length of the supplied string 
and reads exacdy that number of bytes from the time capsule; it then compares the bytes 
read with the string. If the two differ, "flag^time_capsule_errorO" is called with the error 
value supplied. If any other errors reading from the time capsule, 
"flag^time.capsule.errorO" is called with the appropriate error code from Table 2. 

The routine "host.check.string^time.capsule" does not need to be exported from the host; 
it is another macro in "timecap.h." This is intended for use when checking for strings in the 
time capsule that act as "anchors" or known points in the lime capsule. The failure to match 
would then indicate that the loading of the time capsule has got "out of phase" with the data 
stored within it. 

The routine "host_read_data_time_capsuIe'' reads the requested number of bytes from the 
time capsule to the specified address. If any other errors reading from the time capsule, 
"flag_time_capsule_errorO" is called with the appropriate enor code from the Table 2. 

The routine "host_read_varjime_capsule" does not need to be provided by the host. It is 
actually a macro in "timecap.h", but is included here for completeness. 
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The routine "host_timc_capsule_rcad_status'* talks to the host user interface code to make 
an appropriate error message get displayed on the screen to explain to the user what went 
wrong with time capsule loading. If the parameter "must_quit^ is true, then this routine must 
terminate the SoftWindows run immediately the user has acknowledged the error. It is also 
5 called when the time capsule is loaded OK. The code supplied in this case is TCERR.OK", 
and "must_quit" is false. 

Tlie routine "host.close.time.capsule" doses the time capsule. This routine is used whether 
the time capsule was being written or read. 

10 

The routine "host_delete_tinie_capsule'* requests that the host delete the time capsule. 

The routine "host_save_tojime_capsule" is called during time capsule creation and allows 
each host to call the time capsule save routines for any host modules that need to save state. 

15 

The routine "host Joad_from.time.capsuIe" is called during time capsule loading and allows 
each host to call the time capsule load routines for any host modules that need to load state. 
Obviously the calls in this routine should be in a corresponding order to those in 
"host_save_to_time_capsuleO". 

20 

Having described in detail one embodiment of the invention, it should be noted that many 
modifications and developments may be made thereto. Accordingly, the embodiment 
described above with reference to the drawings should not be taken as limiting the scope 
of the invention. For example, the invention may be employed on other physical computer 
25 systems emulating computer systems other than PCs and running operating systems other 
than Windows 95, for example other versions of Microsoft Windows, Solaris, Nextstep, 
Linux, and so on. 



CLAIMS 



1. A method of operating a physical computer system of a first type, the method 
comprising the steps of: 

performing an emulation session on the physical computer system in which the 
physical computer system emulates an emulated computer system of a second different type 
and in which an operating system is operating on the emulated computer system; 

shutting-down the emulation session, the shutting down step including the step of 
storing the values of those volatile variables necessary to define the state of the emulated 
computer system at the start of the shutting-down step; and 

subsequently starting a emulation session in which the values of the volatile variables 
are restored from the stored values so as to restore the emulated computer system to its state 
at the start of the preceding shutting-down step. 



2. A method as claimed in claim 1, wherein the session starting step includes the steps 
of: 

determining whether or not values have been stored defining the state of the 
emulated computer system at the start of a preceding shutting-down step; and 
if not booting the operating system to an initial state. 



3. A method as claimed in claim 1 or 2. wherein the session starting step includes the 
steps of: 

determining whether or not values which have been stored defining the state of the 
emulated computer system at the start of a . preceding shutting-down step are valid; and 
if not: 

deleting those stored values; and 

inhibiting the starting of an emulation session using those values. 



4. 



A method as claimed in any preceding claim, wherein: 

the operating system of the emulated computer system provides a graphical 
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interface; and 

the shutting-down step includes the step, prior to the step of storing the values of 
the volatile variables, of placing the emulated system in a state in which the graphical user 
interface is not displayed. 

5. A method as claimed in any preceding claim, wherein: 

the emulated computer system employs a power management system; and 

in the shutting down step, at least one suspension request is made to the power 

management system, which in turn makes at least one suspension request to the operating 

system of the emulated computer system. 



6. A method as claimed in any preceding claim, wherein: 

the emulated computer system employs a plurality of function pointers; 

a database is maintained of every function to which the function pointers can point; 

during the shutting down step, the values of the function pointers arc encoded 
according to the positions of the respective functions in the database; and 

during the session starting step, the encoded values of the function pointers arc 
decoded according to the functions at the respective positions in the database. 



7. A method as claimed in any preceding claim, wherein the physical computer system 
is other than a PC, the emulated computer system is a PC, and the operating system is 
25 Windows. 



8. A method of operating a physical computer system, substantially as described with 
reference to the drawings. 

30 



9. A computer system adapted to perform the method as claimed in any preceding 
claim. 
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10. A physical computer system of a first type, comprising: 

a volatile memory for storing values of variables; 

a permanent storage means for storing values of variables; 

an operating system for operating on a computer system of a second different type; 
5 means for performing an emulation session on the physical computer system in 

which the physical computer system emulates the computer system of the second type and 
in which the operating system can operate on the emulated computer system; 

means operable to shut-down such an emulation session including storing in the 
pennanent storage means the values of those variables in the volatile memory necessary to 
10 define the state of the emulated computer system at the start of operation of the shutting- 
down means; and 

means operable to start a subsequent emulation session including restoring from the 
stored values in the permanent storage means the values of the variables in the volatile 
memory so as to restore the emulated computer system to its state at the start of the 
15 preceding operation of the shutting-down means. 

11. A system as claimed in claim 10, wherein the session starting means includes: 

means for determining whether or not values have been stored in the permanent 
20 storage means dcfming the state of the emulated computer system at the start of the 
preceding operation of the shutting-down means; and if not for booting the operating system 
to an initial state. 

25 12. A system as claimed in claim 10 or 11, wherein the session starting means includes: 
means for determining whether or not values which have been stored defining the 
state of the emulated computer system at the start of the preceding operation of the 
shutting-down means are valid; and if not: for deleting those stored values; and for 
inhibiting the starting of an emulation session using those values. 

30 

13. A system as claimed in any of clums 10 to 12, wherein: 

the operating system of the emulated computer system provides a graphical user 



interface; and 

the shutting-down means includes means operable, prior to storing of the values of 
the volatile variables, to place the emulated system in a state in which the graphical user 
interface is not displayed. 

14. A system as claimed in any of claims 10 to 13, wherein: 

the emulated computer system employs a power management system; and 
the shutting down means includes means to make at least one suspension request to 
the power management system, and the power management system includes means, in tum, 
to make at least one suspension request to the operating system of the emulated computer 
system. 

15. A system as claimed in any of claims 10 to 14, wherein: 

the emulated computer system employs a plurality of function pointers; 

a database is maintained of every function to which the function pointers can point; 

the shutting down means includes means to encode the values of the function 
pointers according to the positions of the respective functions in the database; and 

the session starting means includes means to decode the encoded values of the 
function pointers according to the functions at the respective positions in the database. 

16. A system as claimed in any of claims 10 to 15, wherein the physical computer 
system is other than a PC. the emulated computer system is a PC, and the operating system 
is Windows. 



17. A physical computer system, substantially as described with reference to the 
drawings. 
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